# 백업 전략 (Backup Strategy)

## 1. 개요
백업 전략이란 시스템 장애, 데이터 손실, 또는 사이버 공격과 같은 예기치 못한 상황 발생 시 데이터를 안전하게 복구하기 위해 데이터를 복제하고 보관하는 체계적인 계획을 의미한다.

현대 IT 환경에서 데이터는 기업의 핵심 자산이며, 다음과 같은 다양한 데이터 손실 시나리오에 대비해야 한다.
*   **하드웨어 장애:** 디스크 물리적 손상(Bad Sector), 컨트롤러 고장 등
*   **인적 실수:** 관리자의 실수로 인한 데이터 삭제, 잘못된 설정 변경
*   **악의적 공격:** 랜섬웨어(Ransomware)를 통한 데이터 암호화 및 파괴, 해킹으로 인한 데이터 유출 및 삭제
*   **자연 재해:** 화재, 홍수, 지진 등으로 인한 데이터 센터 물리적 파괴

따라서 단순한 복제를 넘어, 비즈니스 연속성을 보장하기 위해 데이터의 중요도와 복구 목표를 고려한 정교한 백업 전략 수립이 필수적이다.

## 2. 백업의 기본 유형
백업은 데이터의 변경 사항을 어떻게 처리하느냐에 따라 크게 세 가지 유형으로 나뉜다.

### 2.1 전체 백업 (Full Backup)
선택한 모든 데이터를 매번 전체적으로 복사하는 방식이다. 복구가 가장 단순하고 빠르지만, 백업 시간이 길고 저장 공간 소모가 매우 크다.

### 2.2 증분 백업 (Incremental Backup)
마지막 **성공한** 백업(전체 또는 증분) 이후 변경된 데이터만 백업하는 방식이다. 백업 속도가 매우 빠르고 저장 공간을 효율적으로 사용하지만, 복구 시 전체 백업본과 모든 증분 백업본이 순차적으로 필요하므로 복구 시간이 길고 복잡하다.

### 2.3 차등 백업 (Differential Backup)
마지막 **전체 백업 이후** 변경된 모든 데이터를 백업하는 방식이다. 증분 백업보다 저장 공간을 더 많이 사용하지만, 복구 시에는 '전체 백업본 + 최신 차등 백업본' 두 가지만 있으면 되므로 복구 속도가 증분 백업보다 빠르다.

### [표] 백업 유형별 비교
| 구분 | 전체 백업 (Full) | 증분 백업 (Incremental) | 차등 백업 (Differential) |
| :--- | :---: | :---: | :---: |
| **백업 소요 시간** | 매우 김 | 매우 짧음 | 중간 |
| **저장 공간 소모** | 매우 많음 | 매우 적음 | 중간 |
| **복구 속도** | 매우 빠름 | 느림 (순차 복구 필요) | 빠름 |
| **복구 복잡도** | 낮음 | 높음 | 중간 |

## 3. 백업 설계 원칙: 3-2-1 법칙
데이터의 안전성을 극대화하기 위해 업계에서 표준으로 권장하는 전략이 **'3-2-1 백업 법칙'**이다.

1.  **3 (Three Copies):** 원본 데이터를 포함하여 최소 **3개의 데이터 복사본**을 유지한다.
2.  **2 (Two Media):** 최소 **2가지 이상의 서로 다른 저장 매체**를 사용한다. (예: HDD와 LTO 테이프, NAS와 클라우드) 이는 특정 매체의 결함으로 인한 동시 손실을 방지하기 위함이다.
3.  **1 (One Offsite):** 최소 **1개의 복사본은 원격지(Offsite)**에 보관한다. 물리적으로 떨어진 장소나 클라우드 저장소를 활용하여 화재, 지진 등 지역적 재난에 대비한다.

## 4. 백업 매체 및 저장소 전략
환경과 예산, 복구 목표에 따라 적절한 저장소를 선택해야 한다.

### 4.1 온프레미스 (On-premises) 저장소
*   **HDD/SSD:** 빠른 접근 속도를 가지며 소규모 백업에 적합하다.
*   **NAS (Network Attached Storage):** 네트워크 연결 저장소로, 여러 서버의 데이터를 통합 관리하기 용이하다.
*   **LTO Tape:** 대용량 데이터를 장기 보관(Archiving)하는 데 최적화되어 있으며, 전력 소모가 없고 물리적 분리가 쉬워 오프라인 백업(Air-gap)에 유리하다.

### 4.2 클라우드 저장소
*   **Object Storage:** S3와 같은 객체 저장소로, 확장성이 무한하며 API를 통한 자동화가 쉽다.
*   **Cloud Backup Service:** 백업 스케줄링, 버전 관리, 암호화를 통합 제공하는 서비스이다.

## 5. 복구 목표 설정 (RPO와 RTO)
비즈니스 연속성 계획(BCP, Business Continuity Planning)을 수립할 때 가장 중요한 두 가지 지표이다.

*   **RPO (Recovery Point Objective, 복구 지점 목표):** 데이터 손실을 얼마나 허용할 것인가에 대한 지표이다. 예를 들어 RPO가 1시간이라면, 최대 1시간 분량의 데이터 손실은 감수하며 1시간마다 백업을 수행해야 함을 의미한다.
*   **RTO (Recovery Time Objective, 복구 시간 목표):** 장애 발생 후 서비스가 정상화될 때까지 걸리는 최대 허용 시간이다. RTO가 4시간이라면, 어떤 상황에서도 4시간 이내에 시스템을 복구해야 한다.

### [표] 서비스 중요도에 따른 RPO/RTO 설정 예시
| 서비스 등급 | RPO (데이터 손실 허용치) | RTO (서비스 중단 허용치) | 권장 전략 |
| :--- | :---: | :---: | :--- |
| **핵심 서비스 (Critical)** | 실시간 $\sim$ 수 분 | 수 분 $\sim$ 1시간 | 실시간 미러링, Hot-Standby 구성 |
| **주요 서비스 (Important)** | 1시간 $\sim$ 24시간 | 4시간 $\sim$ 24시간 | 일간 백업, 자동화된 복구 스크립트 |
| **일반 서비스 (Normal)** | 24시간 $\sim$ 1주일 | 1일 $\sim$ 1주일 | 주간 백업, 수동 복구 프로세스 |

## 6. 추가 개념: 스냅샷 vs 미러링
백업과 혼동하기 쉬운 개념으로, 각각의 특성이 다르므로 용도에 맞게 사용해야 한다.

| 구분 | 스냅샷 (Snapshot) | 미러링 (Mirroring) |
| :--- | :--- | :--- |
| **정의** | 특정 시점의 데이터 상태를 기록한 '사진'과 같은 복제본 | 데이터를 실시간으로 동일하게 복제하는 방식 (RAID 1 등) |
| **특징** | 포인터 기반으로 빠르게 생성, 과거 시점으로 롤백 가능 | 실시간 동기화, 한쪽 장애 시 즉시 서비스 가능 |
| **한계** | 원본 데이터가 손상되면 스냅샷도 영향을 받을 수 있음 | **실수(삭제)나 바이러스 감염이 실시간으로 복제됨** |
| **용도** | 업데이트 전 상태 저장, 빠른 복구 지점 생성 | 고가용성(HA) 확보, 하드웨어 장애 대비 |

## 7. 불변성 백업 및 에어 갭 (Immutable Backup & Air-gap)
최근 랜섬웨어가 백업 서버까지 공격하여 백업본을 삭제하거나 암호화하는 사례가 급증함에 따라, 수정 불가능한 백업 전략이 중요해지고 있다.

### 7.1 불변성 백업 (Immutable Backup)
한 번 기록되면 정해진 기간 동안 수정이나 삭제가 불가능한 백업 방식이다.
*   **WORM (Write Once Read Many):** 한 번 쓰면 읽기만 가능한 저장 매체 기술.
*   **S3 Object Lock:** 클라우드 객체 저장소에서 특정 기간 동안 객체 삭제 및 수정을 금지하는 기능.

### 7.2 에어 갭 (Air-gap)
백업 대상과 백업 저장소 사이의 모든 네트워크 연결을 물리적 또는 논리적으로 완전히 차단하는 전략이다.
*   **물리적 에어 갭:** LTO 테이프 백업 후 테이프를 물리적으로 분리하여 금고에 보관하는 방식.
*   **논리적 에어 갭:** 평소에는 네트워크를 차단하고, 백업 시에만 일시적으로 연결한 뒤 다시 차단하는 자동화된 게이트웨이 방식.
*   **효과:** 네트워크를 통해 전파되는 랜섬웨어나 해킹 공격이 백업본에 도달하는 경로를 원천적으로 차단한다.

## 8. 백업 주기 및 등급 가이드

### 8.1 데이터 중요도별 백업 등급 분류
모든 데이터를 동일한 주기로 백업하는 것은 자원 낭비이므로, 중요도에 따라 등급을 나누어 관리한다.

| 등급 | 중요도 | 대상 예시 | 권장 백업 주기 | 보관 기간 |
| :---: | :---: | :--- | :---: | :---: |
| **Tier 1** | 치명적 | 고객 결제 정보, 핵심 DB, 설정 파일 | 실시간 ~ 1시간 | 7년 이상 |
| **Tier 2** | 높음 | 업무용 문서, 프로젝트 소스 코드 | 일간 (Daily) | 1년 ~ 3년 |
| **Tier 3** | 보통 | 로그 파일, 임시 작업 데이터 | 주간 (Weekly) | 1개월 ~ 3개월 |
| **Tier 4** | 낮음 | 단순 참조 자료, 오래된 아카이브 | 월간 (Monthly) | 필요 시까지 |

### 8.2 백업 주기 설정 가이드
1.  **데이터 변경 빈도 분석:** 데이터가 얼마나 자주 변경되는지 파악하여 RPO를 설정한다.
2.  **백업 윈도우(Backup Window) 확인:** 시스템 부하를 최소화하기 위해 서비스 이용자가 적은 시간대를 백업 시간으로 지정한다.
3.  **순환 주기 설정:** 실무에서는 보통 다음과 같은 조합을 사용한다.
    *   (예: 매주 일요일 전체 백업 $\rightarrow$ 평일 매일 증분 백업)
    *   (예: 매주 일요일 전체 백업 $\rightarrow$ 평일 매일 차등 백업)

## 9. 백업 검증 및 유지관리
백업 파일이 존재한다고 해서 복구가 보장되는 것은 아니다. **"백업의 완성은 복구 확인이다."**

### 9.1 복구 테스트 (Restore Test)
*   **정기적 복구 훈련:** 분기 또는 반기별로 실제 백업본을 이용해 별도의 테스트 서버에 복구하는 과정을 수행한다.
*   **무결성 검사:** 체크섬(Checksum) 확인 등을 통해 백업 파일이 깨지지 않았는지 검증한다.

### 9.2 자동화 및 로그 관리
백업 프로세스를 자동화하고, 성공/실패 여부를 즉시 알림(Slack, Email 등)으로 받아야 한다.

**[예시] 간단한 리눅스 쉘 스크립트를 이용한 DB 백업 및 로그 기록**
```bash
#!/bin/bash

# 설정
BACKUP_DIR="/backup/db"
DATE=$(date +%Y%m%d_%H%M%S)
LOG_FILE="/var/log/backup.log"
DB_NAME="production_db"

# 백업 실행 (mysqldump 예시)
echo "[$DATE] Backup started for $DB_NAME" >> $LOG_FILE

if mysqldump -u root -p'password' $DB_NAME > $BACKUP_DIR/db_backup_$DATE.sql; then
    echo "[$DATE] Backup successful" >> $LOG_FILE
else
    echo "[$DATE] Backup failed!" >> $LOG_FILE
    # 여기서 관리자에게 알림 전송 로직 추가 가능
    exit 1
fi

# 30일 지난 오래된 백업 파일 삭제 (유지관리)
find $BACKUP_DIR -type f -mtime +30 -delete
```
⚠️ **주의:** 실제 환경에서는 `-p'password'`와 같이 비밀번호가 평문으로 노출되는 방식은 보안상 매우 위험합니다. `.my.cnf` 파일이나 환경 변수, Secret Manager를 사용하여 비밀번호 노출을 방지해야 합니다.